home *** CD-ROM | disk | FTP | other *** search
/ Aminet 31 / Aminet 31 (1999)(Schatztruhe)[!][Jun 1999].iso / Aminet / util / arc / bzip2.lha / bzip2 / bzip2.txt < prev    next >
Text File  |  1999-04-24  |  17KB  |  356 lines
  1.  
  2. bzip2(1)                                                 bzip2(1)
  3.  
  4.  
  5. NAME
  6.        bzip2, bunzip2 - a block-sorting file compressor, v0.9.0
  7.        bzcat - decompresses files to stdout
  8.        bzip2recover - recovers data from damaged bzip2 files
  9.  
  10.  
  11. SYNOPSIS
  12.        bzip2 [ -cdfkstvzVL123456789 ] [ filenames ...  ]
  13.        bunzip2 [ -fkvsVL ] [ filenames ...  ]
  14.        bzcat [ -s ] [ filenames ...  ]
  15.        bzip2recover filename
  16.  
  17.  
  18. DESCRIPTION
  19.        bzip2  compresses  files  using the Burrows-Wheeler block-
  20.        sorting text compression algorithm,  and  Huffman  coding.
  21.        Compression  is  generally  considerably  better than that
  22.        achieved by more conventional LZ77/LZ78-based compressors,
  23.        and  approaches  the performance of the PPM family of sta-
  24.        tistical compressors.
  25.  
  26.        The command-line options are deliberately very similar  to
  27.        those of GNU Gzip, but they are not identical.
  28.  
  29.        bzip2  expects  a list of file names to accompany the com-
  30.        mand-line flags.  Each file is replaced  by  a  compressed
  31.        version  of  itself,  with  the  name "original_name.bz2".
  32.        Each compressed file has the same  modification  date  and
  33.        permissions  as  the corresponding original, so that these
  34.        properties can  be  correctly  restored  at  decompression
  35.        time.  File name handling is naive in the sense that there
  36.        is no mechanism for preserving original file  names,  per-
  37.        missions  and  dates  in filesystems which lack these con-
  38.        cepts, or have serious file name length restrictions, such
  39.        as MS-DOS.
  40.  
  41.        bzip2  and  bunzip2 will by default not overwrite existing
  42.        files; if you want this to happen, specify the -f flag.
  43.  
  44.        If no file names  are  specified,  bzip2  compresses  from
  45.        standard  input  to  standard output.  In this case, bzip2
  46.        will decline to write compressed output to a terminal,  as
  47.        this  would  be  entirely  incomprehensible  and therefore
  48.        pointless.
  49.  
  50.        bunzip2 (or bzip2 -d ) decompresses and restores all spec-
  51.        ified files whose names end in ".bz2".  Files without this
  52.        suffix are ignored.  Again, supplying no filenames  causes
  53.        decompression from standard input to standard output.
  54.  
  55.        bunzip2 will correctly decompress a file which is the con-
  56.        catenation of two or more compressed files.  The result is
  57.        the concatenation of the corresponding uncompressed files.
  58.        Integrity testing (-t) of concatenated compressed files is
  59.        also supported.
  60.  
  61.        You  can also compress or decompress files to the standard
  62.        output by giving the -c flag.  Multiple files may be  com-
  63.        pressed and decompressed like this.  The resulting outputs
  64.        are fed sequentially to stdout.  Compression  of  multiple
  65.        files  in this manner generates a stream containing multi-
  66.        ple compressed file representations.  Such a stream can be
  67.        decompressed  correctly  only  by  bzip2  version 0.9.0 or
  68.        later.  Earlier versions of bzip2 will stop  after  decom-
  69.        pressing the first file in the stream.
  70.  
  71.        bzcat  (or bzip2 -dc ) decompresses all specified files to
  72.        the standard output.
  73.  
  74.        Compression is always performed, even  if  the  compressed
  75.        file  is slightly larger than the original.  Files of less
  76.        than about one hundred bytes tend to get larger, since the
  77.        compression  mechanism  has  a  constant  overhead  in the
  78.        region of 50 bytes.  Random data (including the output  of
  79.        most  file  compressors)  is  coded at about 8.05 bits per
  80.        byte, giving an expansion of around 0.5%.
  81.  
  82.        As a self-check for your  protection,  bzip2  uses  32-bit
  83.        CRCs  to make sure that the decompressed version of a file
  84.        is identical to the original.  This guards against corrup-
  85.        tion  of  the compressed data, and against undetected bugs
  86.        in bzip2 (hopefully very unlikely).  The chances  of  data
  87.        corruption  going  undetected  is  microscopic,  about one
  88.        chance in four billion for each file processed.  Be aware,
  89.        though,  that  the  check occurs upon decompression, so it
  90.        can only tell you that that something is wrong.  It  can't
  91.        help  you recover the original uncompressed data.  You can
  92.        use bzip2recover to  try  to  recover  data  from  damaged
  93.        files.
  94.  
  95.        Return  values:  0  for a normal exit, 1 for environmental
  96.        problems (file not found, invalid flags, I/O errors,  &c),
  97.        2 to indicate a corrupt compressed file, 3 for an internal
  98.        consistency error (eg, bug) which caused bzip2 to panic.
  99.  
  100.  
  101. MEMORY MANAGEMENT
  102.        Bzip2 compresses large files in blocks.   The  block  size
  103.        affects  both  the  compression  ratio  achieved,  and the
  104.        amount of memory needed both for  compression  and  decom-
  105.        pression.   The flags -1 through -9 specify the block size
  106.        to be 100,000 bytes through 900,000  bytes  (the  default)
  107.        respectively.   At decompression-time, the block size used
  108.        for compression is read from the header of the  compressed
  109.        file, and bunzip2 then allocates itself just enough memory
  110.        to decompress the file.  Since block sizes are  stored  in
  111.        compressed  files,  it follows that the flags -1 to -9 are
  112.        irrelevant  to  and  so  ignored   during   decompression.
  113.  
  114.        Compression  and decompression requirements, in bytes, can
  115.        be estimated as:
  116.  
  117.              Compression:   400k + ( 7 x block size )
  118.  
  119.              Decompression: 100k + ( 4 x block size ), or
  120.                             100k + ( 2.5 x block size )
  121.  
  122.        Larger  block  sizes  give  rapidly  diminishing  marginal
  123.        returns;  most of the compression comes from the first two
  124.        or three hundred k of block size, a fact worth bearing  in
  125.        mind  when  using  bzip2  on  small  machines.  It is also
  126.        important to  appreciate  that  the  decompression  memory
  127.        requirement  is  set  at compression-time by the choice of
  128.        block size.
  129.  
  130.        For files compressed with the  default  900k  block  size,
  131.        bunzip2  will require about 3700 kbytes to decompress.  To
  132.        support decompression of any file on a 4 megabyte machine,
  133.        bunzip2  has  an  option to decompress using approximately
  134.        half this amount of memory, about 2300 kbytes.  Decompres-
  135.        sion  speed  is also halved, so you should use this option
  136.        only where necessary.  The relevant flag is -s.
  137.  
  138.        In general, try and use the largest block size memory con-
  139.        straints  allow,  since  that  maximises  the  compression
  140.        achieved.  Compression and decompression speed are  virtu-
  141.        ally unaffected by block size.
  142.  
  143.        Another  significant point applies to files which fit in a
  144.        single block -- that  means  most  files  you'd  encounter
  145.        using  a  large  block  size.   The  amount of real memory
  146.        touched is proportional to the size of the file, since the
  147.        file  is smaller than a block.  For example, compressing a
  148.        file 20,000 bytes long with the flag  -9  will  cause  the
  149.        compressor  to  allocate  around 6700k of memory, but only
  150.        touch 400k + 20000 * 7 = 540 kbytes of it.  Similarly, the
  151.        decompressor  will  allocate  3700k  but only touch 100k +
  152.        20000 * 4 = 180 kbytes.
  153.  
  154.        Here is a table which summarises the maximum memory  usage
  155.        for  different  block  sizes.   Also recorded is the total
  156.        compressed size for 14 files of the Calgary Text  Compres-
  157.        sion  Corpus totalling 3,141,622 bytes.  This column gives
  158.        some feel for how  compression  varies  with  block  size.
  159.        These  figures  tend to understate the advantage of larger
  160.        block sizes for larger files, since the  Corpus  is  domi-
  161.        nated by smaller files.
  162.  
  163.                   Compress   Decompress   Decompress   Corpus
  164.            Flag     usage      usage       -s usage     Size
  165.  
  166.             -1      1100k       500k         350k      914704
  167.             -2      1800k       900k         600k      877703
  168.             -3      2500k      1